A software container is an instance of a user-space running an application within the operating system (OS) of a host device (e.g., a server). Software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers.
A software container (also known as a container) provides an executable environment with a complete filesystem. The filesystem may contain code, runtime, system tools, system libraries, and so on. That is, execution of a software container can be the same regardless of the underlying infrastructure. A Docker is one of the popular existing platforms for creating, migrating, managing, and deploying software containers.
A software container, unlike a virtual machine, does not require or include a separate operating system. Rather, the container relies on the kernel's functionality and uses hardware resources (CPU, memory, I/O, network, etc.) and separate namespaces to isolate the application's view of the operating system. A software container can access the OS kernel's virtualization features either directly or indirectly. For example, Linux® Kernel can be accessed directly using the libcontainer library or indirectly using the libvirt service.
As demonstrated in FIG. 1, a number of software containers (i.e., the app containers 110-1 through 110-n, hereinafter referred to individually as a container 110, merely for simplicity purposes) can access and share the same OS kernel 120. However, each software container 110 can be constrained to only use a defined amount of hardware resources (e.g., CPU, memory, etc.) in the underlying hardware layer 130 of the host 150. Thus, using software containers, hardware resources can be isolated, services can be restricted, and processes can be provisioned to have an almost completely private view of the operating system with their own process ID space, file system structure, and network interfaces.
FIG. 2 illustrates a typical structure of an image of a software container (hereinafter a “container image”) 200. The container image 200 includes a base image 210 and a container layer 220. The base image 210 includes one or more image layers 215-1 through 215-q (hereinafter referred to individually as a layer 215 and collectively as layers 215, merely for simplicity purposes). The layers 215 are read-only layers that represent filesystem differences. That is, the layers 215 are stacked on top of each other to form a base for the root file system of the container image 200. The layers 215 are read only, and each layer 215 is identified by a randomly generated identifier number of a checksum computed using a hash function.
The base image 210 (and its layers 215) can be shared across different software containers. Thus, only the container layer 220, which is the top layer, differentiates between one software container and another. The container layer 220 is a readable and writable layer where all data written to the container image 200 are saved in the container layer 220. The container layer 220 defines the application of an application container when executed. The container image 200 is a static file and the application container is a runtime instance of the container image 200. When the container image 200 is deleted, the writable container layer 220 is also deleted, and the base image 210 remains unchanged. As such, the multiple container images 200 can share access to the same base image 210, each of which has its own data state. In the example demonstrated in FIG. 2, the software container 200 is a Docker container (e.g., compliant with the Docker platform).
The container image 200 may include one or more root certificates (not shown). A root certificate is part of a public key infrastructure scheme. Such a scheme typically includes a digital signature from a certificate authority. A certificate authority (CA) can issue multiple certificates in the form of a tree structure. A root certificate is the top-most certificate of the tree, the private key of which is used to “sign” other certificates.
The root certificates may be trusted by the creator of the container image 200, but not by the host executing the respective software container. For example, a root certificate may be a legitimate self-signed certificate. However, the host 150 (FIG. 1) when executing the respective application container (e.g., container 110-1) may not recognize or trust the certificate. The app container may run a malicious code that can exploit a root certificate untrusted by the host. For example, the certificate may be a self-signed root HTTPS certificate that can intercept encrypted traffic sent or received from websites. When an HTTPS website is accessed, the website certificate is signed and controlled by the certificate and malicious code that are being falsely represented as a root certificate trusted by the host.
Typically, an application container can be secured separately from other application containers. Thus, one software container cannot access the resources of other software containers. However, the isolation of application containers cannot prevent the execution of malicious code. Malicious activity by software containers can occur through exploitation of at least root certificates (and other programs) defined in the container. For example, a root certificate's vulnerabilities containers can be exploited to carry out HTTPS man-in-the-middle attacks where encrypted traffic can be hijacked by an attacker.
To prevent integration of malicious images containing un-trusted root certificates in an application (APP) container, detection of vulnerabilities in images should occur prior to the execution of the application container.
Existing security solutions are not designed to detect vulnerabilities in images of application containers. Specifically, images have a specific structure that cannot be processed by existing security solutions. For example, a conventional antivirus tool cannot scan images to detect computer viruses, as such a tool cannot extract the different layers of an image and cannot parse each layer to analyze its contents.
In addition, currently there is no security tool that can check for vulnerabilities in base images, as such images are uploaded to a registry (e.g., during a continuous integration process). As the popularity of software containers has increased due to the easy integration with cloud-computing platforms (e.g., Amazon® Web Services, Google® Cloud Platform, Microsoft® Azure, etc.), the lack of defense against vulnerable container images and root certificates is a major drawback.
It would be therefore advantageous to provide a solution that would secure base images of software containers and image registries.